WD-insert-951201
WD-insert-951201This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR
Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support the insertion of multimedia objects including Microsoft Component Object Model (COM) objects (e.g. OLE Controls and OLE Document embeddings), Java applets, and a wide range of other media plugins. The approach allows objects to be specified in a general manner and provides the ability to override the default implementation of objects.
HTML 2.0 defined only a single mechanism for inserting media into HTML documents: the IMG tag. While this tag has certainly proved worthwhile, the fact that it is restricted to image media severely limits it usefulness as richer and richer media finds its way onto the Web.
Developers have been experimenting with ideas for dealing with new media: Microsoft's DYNSRC attribute for video and audio, Netscape's EMBED tag for compound document embedding, and Sun's APP and APPLET tags for executable code.
Each of these proposed solutions attacks the problem from a slightly different perspective, and on the surface are each very different. In addition, each of these proposals falls short, in one way or another, of meeting the requirements of the Web community as a whole. However, we believe that this problem can be addressed with a single extension that addresses all of the current needs, and is fully extensible for the future.
This specification defines a new tag <INSERT> which subsumes the role of the IMG tag, and provides a general solution for dealing with new media, while providing for effective backwards compatibility with existing browsers. INSERT allows the HTML author to specify the data, including persistent data and/or properties/parameters for initializing objects to be inserted into HTML documents, as well as the code that can be used to display/manipulate that data. Here, the term object is used to describe the things that people want to place in HTML documents, but other terms for these things are: components, applets, plugins, media handlers, etc.
The data can be specified in one of several ways: via a universally unique object identifier (uuid) (<<REFERENCE OSF/DCE RPC Specification>>), a file specified by a URL, in-line data, or as a set of named properties. In addition, there are a number of attributes that allow authors to specify standard properties such as width, and height. The code for the object is specified in several ways: indirectly by the object's uuid, by information included as part of the object's data, and the combination of an object class name and a network address.
This specification covers the syntax and semantics for inserting such objects into HTML documents, but leaves out the architectural and application programming interface issues for how objects communicate with the document and other objects on the same page. It is anticipated that future specifications will cover these topics, including scripting languages and interfaces.
This section is intended to help readers get the feel of the insertion mechanism, and is not a normative part of the specification. The INSERT tag provides a richer alternative to the IMG tag. It may be used when the author wishes to provide an alternative for user agents that don't support a particular media. A simple example of using INSERT is:
<insert data=TheEarth.avi type="application/avi">
<param name=loop value=infinite>
<img src=TheEarth.gif alt="The Earth">
</insert>
Here the user agent would show an animation if it supports the AVI format, otherwise it would show a GIF image. The IMG element is used for the latter as it provides for backwards compatibility with existing browsers. The TYPE attribute allows the user agent to quickly detect that it doesn't support a particular format, and hence avoid wasting time downloading the object. Another motivation for using the TYPE attribute is when the object is loaded off a CD-ROM, as it allows the format to be specified directly rather than being inferred from the file extension.
The next example inserts an OLE control for a clock:
<insert
id=clock1
type="application/x-oleobject"
data="http://www.foo.bar/test.stm"
code="http://www.foo.bar/controls"
>
</insert>
The ID attribute allows other controls on the same page to locate the clock. The DATA attribute points to the persistent stream data used to initialize the object's state. It includes a class identifier. The CODE attribute points to a file containing the implementation for this object. The file may contain the code for several classes, but this can be resolved by the class id from the object's data stream.
In the absence of the CODE attribute, the class identifier may be sufficient to locate the code implementing this object. User agents may provide a range of mechanisms for locating and downloading such code. For some formats such as image files, the Internet media type returned with the data is sufficient.
The class identifier can be specified explicitly using the CLASSID attribute. This value takes precedence over a class identifier included as part of the object's data, e.g.
<insert
id=clock1
type="application/x-oleobject"
classid="uuid:{663C8FEF-1EF9-11CF-A3DB-080036F12502}"
data="http://www.acme.com/ole/clock.stm"
>
</insert>
Are the curly brackets really needed for guid's?
Yes. Standard string representation for uuid includes the brackets. -cek
For speedy loading of objects you can inline the object's state data using the new URL scheme "data:", e.g.
<insert
id=clock1
classid="uuid:{663C8FEF-1EF9-11CF-A3DB-080036F12502}"
data="data:34hqi6n3gs9c3hdish2h568fhsb3uds7b4jawkl5h"
type="application/x-oleobject; clsid=no"
>
</insert>
The data is expressed as a Base64 encoded byte stream. The interpretation of this stream is class dependent. If the CLASSID attribute is missing or is insufficient to disambiguate the precise format of this stream then the TYPE attribute may be used to resolve matters. In the example, the Internet media type for COM streams takes a parameter that indicates that the stream doesn't start with a class identifier.
The next example is a Java applet:
<insert
code="http://java.acme.com/applets/NervousText.class"
width=400
height=75
align=center
>
<param name=text value="This is the Applet Viewer">
</insert>
The CODE attribute points to the file containing the implementation of the NervousText class. There is only one class per file, so this is unambigous. The other attributes on the INSERT element define rendering properties of the container for the applet viewer. The PARAM element specifies a named property which is used to initialize the class. PARAM elements can be combined with data streams for greater control.
The document type definition provides the formal definition of the allowed syntax for HTML inserts. The following is an annotated listing of the DTD. The complete listing appears at the end of this document.
Several attributes specify lengths as a number followed by an optional suffix. The units for lengths are specified by the suffix: pt denotes points, pi denotes picas, in denotes inches, cm denotes centimeters, mm denotes millimeters, em denotes em units (equal to the height of the default font), and px denotes screen pixels. The % sign indicates that the value is a percentage of the current displayable region, for widths, this is the space between the current left and right margins, while for heights, this is the height of the current window or table cell etc. The default units are screen pixels. The number is an integer value or a real valued number such as "2.5". Exponents, as in "1.2e2", are not allowed. White space is not allowed between the number and the suffix.
The INSERT element requires both start and end tags. The INSERT element has the same content model as the HTML BODY element, except that one or more optional PARAM or ALIAS elements can be placed immediately after the INSERT start tag and used to initialize the inserted object. The content of the INSERT element is rendered if the object specified by the data, code or classid attributes can't be rendered. This provides for backwards compatibility with existing browsers, and allows authors to specify alternative media via nested INSERT elements.
Note that this doesn't provide the same level of flexibility as would be provided by a richer description of resource variants. For instance when a resource in available are several media types and for each such type in English, Spanish, French and German.
<!-- Content model entities imported from parent DTD:
%body.content allows inserts to contain headers, paras,
lists, form elements and even arbitrarily nested inserts.
-->
<!ENTITY % attrs
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
style CDATA #IMPLIED -- rendering annotation --
dir (ltr|rtl) #IMPLIED -- I18N text direction --
lang NAME #IMPLIED -- as per RFC 1766 --">
<!ENTITY % URL "CDATA" -- universal reference locator -->
<!ENTITY % Align "(top|middle|bottom|left|center|right)">
<!ENTITY % Length "CDATA" -- standard length value -->
<!-- INSERT is a character-like element for inserting objects -->
<!ELEMENT insert - - ((param|alias)*, bodytext)>
<!ATTLIST insert
%attrs -- id, class, style, lang, dir --
data %URL #IMPLIED -- ref to object's data --
code %URL #IMPLIED -- ref to object's code --
classid %URL #IMPLIED -- object's UUID --
type CDATA #IMPLIED -- Internet media type --
align %Align #IMPLIED -- positioning inside document --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
border %Length #IMPLIED -- suggested link border width --
hspace %Length #IMPLIED -- suggested horizontal gutter --
vspace %Length #IMPLIED -- suggested vertical gutter --
usemap %URL #IMPLIED -- ref to image map --
ismap (ismap) #IMPLIED -- use server image map --
>
<!-- the BODYTEXT element is needed to avoid problems with
SGML mixed content, but is never used in actual documents -->
<!ELEMENT bodytext O O %body.content>
In general, all attribute names and values in this specification are case insensitive, except where noted otherwise. INSERT has the following attributes:
en, en-US, en-uk, i-cherokee, x-pig-latin.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
token = 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
tspecials = <one of the set> ( ) < > @ , ; : \ " / [ ] ? =
parameter = attribute "=" value
attribute = token
value = token | quoted-string
This section defines the steps needed to bind an object given various combinations of attributes. Without a precise semantics for this, different user agents would otherwise produce different results to the frustration of authors.
Note is this decision tree over specified? Is it correct? Is there a simpler explanation in terms of precedence rules? Please let the editor know if you have a proposal for this!
In the following, the ExtractClassId function is somewhat simplified. This function depends on recognising the format of the data stream. If the data is inlined, the format may be given by the TYPE attribute or derived from the CLASSID or CODE attributes. The format of the data stream also effects the Invoke function. For instance, the class initialization procedure may require you to adjust the stream pointer to after the class identifier.
This decision tree doesn't make explicit how to deal with the cases where you use the CODE attribute to load the implementation, but need additional information to find the appropriate entry point into this code. This could be provided by the CLASSID attribute or by a class identifier extracted from the data as pointed to by the DATA attribute.
Properties(properties); // collect properties from PARAM elements
Type(type); // get value of TYPE attribute
if CLASSID(clsid) then
if Implementation(clsid, class) then
if (DATA(data)) then
if (Load(data, stream)) then
Invoke(class, stream, params);
else
Fail("Can't load data");
fi
else // no data
Invoke(class, null);
fi
else // no implementation for CLASSID
if CODE(code) then
if Load(code, class) then
if DATA(data then
if Load(data, stream) then
Invoke(class, stream, params);
else
Fail("Can't load data");
fi
else
Invoke(class, null, params);
fi
else // can't load code
if DATA(data) then
if Load(data, stream) then
if ExtractClassId(stream, clsid) then
if Implementation(clsid, class) then
Invoke(class, stream, params);
else
Fail("Can't get implementation");
fi
else
Fail("Can't get implementation");
fi
else
Fail("Can't get implementation");
fi
else // no data
Fail("Can't get implementation");
fi
fi
else // no CODE attribute
if DATA(data) then
if Load(data, stream) then
if ExtractClassId(stream, clsid) then
if Implementation(clsid, class) then
Invoke(class, stream, params);
else
Fail("Can't get implementation");
fi
else
Fail("Can't get implementation");
fi
else
Fail("Can't load data");
fi
else
Fail("Can't get implementation");
fi
fi
fi
else // no CLASSID
if CODE(code) then
if Load(code, class) then
if DATA(data) then
if Load(data, stream) then
Invoke(class, stream, params);
else
Fail("Can't load data");
fi
else // no DATA
Invoke(class, null, params);
fi
else
Fail("Can't get implementation");
fi
else // no CODE
if DATA(data) then
if Load(data, stream) then
if ExtractClassID(stream, clsid) then
if Implementation(clsid, class) then
Invoke(class, stream, params);
else
Fail("Can't get implementation");
fi
else
Fail("Can't get implementation");
fi
else
Fail("Can't get implementation");
fi
else
Fail("Can't get implementation");
fi
fi
fi
The PARAM element allows a list of named property values (used to initialize a OLE control, plug-in module or Java applet) to be represented as a sequence of PARAM elements. Note that PARAM is an empty element and should appear without an endtag.
<!ELEMENT param - O EMPTY -- named property value -->
<!ATTLIST param
name CDATA #REQUIRED -- property name --
value CDATA #IMPLIED -- property value --
valueref %URL #IMPLIED -- ref to object ALIAS --
>
The NAME attribute defines the property name. The case sensitivity of the name is dependent on the code implementing the object.
The value attribute is used to specify the property value. It is an opaque character string whose meaning is determined by the object based on the property name. Note that CDATA attribute values need characters such as & to be escaped using the standard SGML character entities. It is also essential to escape the > character to defend against incorrect handling by many existing browsers.
The valueref attribute is used when the property is an object. A distinct attribute is needed as in some cases the property type cannot be deduced from the property name. The valueref attribute provides a URL based reference to an ALIAS element that defines the object itself.
Note do we want a short cut in which valueref specifies the object directly rather than via an alias? For example valueref=foo.gif, or when you want to use inline data with the "data:" URL scheme? This would save having to include an associated ALIAS element, but might require adding a TYPE attribute to the PARAM element.
(I like this idea! "Valueref=data:abcdef00...b34f#name=arial size=10 bold=true". Where the data is just the CLSID. -cek)
The ALIAS element is used to define an object without inserting it into the document. It is used with the valueref attribute of the PARAM element to allow an object to be passed as parameter, when initializing an object associated with another INSERT or ALIAS element. The attributes take exactly the same meaning as for the INSERT element. The ALIAS element is a container and requires both start and end tags. The contents are limited to PARAM and ALIAS elements, although it is anticipated that this may be extended to cover the same content model as INSERT at some point in the future.
<!-- ALIAS is allowed in document HEAD and BODY
it defines an alias for an object without inserting it -->
<!ELEMENT alias - - (param*, alias*)>
<!ATTLIST alias
id ID #REQUIRED -- defines name for alias --
data %URL #IMPLIED -- ref to object's data --
code %URL #IMPLIED -- ref to object's code --
classid %URL #IMPLIED -- object's UUID --
>
Note that the object isn't created until its needed by something that points to it. Each such reference creates a separate copy of the object.
Note What should the user agent do if it can't support a particual aliased object? One answer would be for it to recover and try the contents of the ALIAS element. To allow this to work I have changed the content model for ALIAS from (param|alias)*.
(Good -cek)
This section describes proposals for extending the capabilities of the insertion mechanism as an encouragement and guide to developers wishing to experiment with such features. These ideas are not part of the current specification, and support is not required for conformance with this specification.
Using a GIF image to tile the document background often results in significant delays while the image tile is downloaded. The ability to use a small Java applet or OLE Control to generate the image tile would allow rich background textures and patterns to be used without causing significant delay. As processing speeds increase, the ability to use an object to generate the background would make practical animated backgrounds.
The proposed extension is to allow the BACKGROUND attribute of the BODY element to reference ALIAS elements, for example:
<title>Demo Document</title> <alias id=marble code="http://www.acme.com/applets/marble.class"> </alias> <body background="#marble"> <p>This document has a marble texture generated by a Java applet.
Overlays are useful for reducing network bandwidth needs. For instance, you can place a PNG overlay on top of a JPEG image. If the PNG image is an antialiased text overlay while the JPEG image is a photographic image with a high compression factor, then the two images will take significantly less time to send than a single image combining both layers. Selecting the format and compression for each layer separately allows you to get higher compression for the same level of quality.
Overlays also save time by making caching more effective. For instance you might send a large image on one page, and then make small changes to it on subsequent pages. Using an overlay allows the original large image to be reused, so that only the small changes need to be sent with each successive page.
<!ELEMENT overlay - O EMPTY -- image overlay -->
<!ATTLIST overlay
id ID #IMPLIED -- for naming this overlay --
class NAMES #IMPLIED -- for subclassing element --
style CDATA #IMPLIED -- for attaching style info --
x %Length #IMPLIED -- offset from left of parent --
y %Length #IMPLIED -- offset from top of parent --
width %Length #IMPLIED -- suggested width --
height %Length #IMPLIED -- suggested height --
src %URL #IMPLIED -- network address of object --
>
For instance, here is a road map overlayed on an aerial photograph:
<insert data="photo.jpeg">
<overlay src=grid.png>
</insert>
The SRC attribute of the OVERLAY element could be used together with an ALIAS element. This allows you to create overlays from OLE controls or Java applets.
Many objects will size themselves according to their contents. Another popular feature is likely to be the ability for users to dynamically resize objects, e.g. by dragging size bars. The height and width attributes of the INSERT element can be used as suggested initial values. For instance, images can be automatically resized to match these values. The ability to smoothly magnify an image allows a small image file to fill a large space, and saves network time.
This specification limits objects to a rectangular outline. Of course, the object can render itself with a transparent background to give the effect of a shaped object, but any text flowing past would always follow the rectangular frame around the object.
An obvious extension is to allow the user agent to ask the object for its outline, and to flow text around that outline. To speed up display, it will also be useful to be able to specify an explicit outline as an attribute of the INSERT element, in the same spirit as the width and height attributes. It is strongly suggested that this attribute is called "SHAPE" and that it has exactly the same syntax as the client-side image map proposal.
A time proven idiom for document layout is the figure. This is often an illustration, but may contain textual material separate from the main flow of the document. Figures are typically captioned and floated to between columns or to the top or bottom of a page. It is not uncommon to see separate contents lists for figures and tables, in addition to the main table of contents.
It is proposed that the FIG element is used to create captioned figures:
<!ENTITY % f.align "(left|center|right)">
<!ELEMENT fig - - (caption?, bodytext)>
<!ATTLIST fig
%attrs -- id, class, style, lang, dir --
align %f.align #IMPLIED -- position on page --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
>
<!ENTITY % c.align "(top|bottom|left|right)">
<!ELEMENT caption - - %body.content>
<!ATTLIST caption
%attrs -- id, class, style, lang, dir --
align %c.align #IMPLIED -- position relative to figure --
>
For example:
<fig>
<caption>Mount Washington</caption>
<insert data=http://www.acme.com/images/vista.jpeg>
<p>A spectacular view of Mount Washington during a winter sunset.
</insert>
</fig>
Note that FIG is a block-like element similar to tables. If a user agent supports tables then adding support for figures is quite simple, since the FIG element behaves in the same as a table with a caption and a single cell. Of course some would argue that in this case, why not use the TABLE element. This is an example of approaching HTML with a view to getting a desired visual effect without regard to what the markup means. This makes it hard to export HTML to other document formats, and makes it harder to read the markup, as you now have to guess what the author actually was trying to do.
Image such as GIF and PNG formats allow textual messages to be included with the image data. This provides an appropriate place to store copyright messages since these will then be automatically transferred with the image when it is dragged from the document to the desktop etc. For other formats, copyright notices can be included in HTTP headers, or by wrapping up the objects as MIME multipart files.
Even when information can be included as part of the object's data, it is still useful to present a credit or copyright message to the user as part of the document text. Something immediately visible is more effective that something hidden! The suggested way of handling credits is to use a new character emphasis element CREDIT that can be given as part of the FIG contents, e.g.
<fig>
<insert data=http://www.acme.com/images/vista.jpeg>
<p>A spectacular view of Mount Washington during a winter sunset.
</insert>
<credit>John Smith</credit>
</fig>
The DTD or document type definition provides the formal definition of the allowed syntax for HTML inserts.
<!-- Content model entities imported from parent DTD:
%body.content allows inserts to contain headers, paras,
lists, form elements and even arbitrarily nested inserts.
-->
<!ENTITY % attrs
"id ID #IMPLIED -- element identifier --
class NAMES #IMPLIED -- for subclassing elements --
style CDATA #IMPLIED -- rendering annotation --
dir (ltr|rtl) #IMPLIED -- I18N text direction --
lang NAME #IMPLIED -- as per RFC 1766 --">
<!ENTITY % URL "CDATA" -- universal reference locator -->
<!ENTITY % Align "(top|middle|bottom|left|center|right)">
<!ENTITY % Length "CDATA" -- standard length value -->
<!-- INSERT is a character-like element for inserting objects -->
<!ELEMENT insert - - ((param|alias)*, bodytext)>
<!ATTLIST insert
%attrs -- id, class, style, lang, dir --
data %URL #IMPLIED -- ref to object's data --
code %URL #IMPLIED -- ref to object's code --
classid %URL #IMPLIED -- object's UUID --
type CDATA #IMPLIED -- Internet media type --
align %Align #IMPLIED -- positioning inside document --
height %Length #IMPLIED -- suggested height --
width %Length #IMPLIED -- suggested width --
border %Length #IMPLIED -- suggested link border width --
hspace %Length #IMPLIED -- suggested horizontal gutter --
vspace %Length #IMPLIED -- suggested vertical gutter --
usemap %URL #IMPLIED -- ref to image map --
ismap (ismap) #IMPLIED -- use server image map --
>
<!-- the BODYTEXT element is needed to avoid problems with
SGML mixed content, but is never used in actual documents -->
<!ELEMENT bodytext O O %body.content>
<!ELEMENT param - O EMPTY -- named property value -->
<!ATTLIST param
name CDATA #REQUIRED -- property name --
value CDATA #IMPLIED -- property value --
valueref %URL #IMPLIED -- ref to object ALIAS --
>
<!-- ALIAS is allowed in document HEAD and BODY
it defines an alias for an object without inserting it -->
<!ELEMENT alias - - (param|alias)*>
<!ATTLIST alias
id ID #REQUIRED -- defines name for alias --
data %URL #IMPLIED -- ref to object's data --
code %URL #IMPLIED -- ref to object's code --
classid %URL #IMPLIED -- object's UUID --
>
The World Wide Web Consortium: http://www.w3.org/pub/WWW/Consortium/